home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
AmigActive 23
/
AACD 23.iso
/
AACD
/
Magazine
/
PC2Amiga
/
Samba
/
docs
/
textdocs
/
NT-Guest-Access.txt
< prev
next >
Wrap
Text File
|
2000-04-25
|
2KB
|
47 lines
!==
!== NT-Guest-Access.txt for Samba release 2.0.7 26 Apr 2000
!==
> Hi folks ... I don't know if you have seen this, have corrected this yet
> or it is my configuration.
> I am using our company PDC for passwd authentication and it works OK
> except for one snag.
> The authentication process between the our Samba server & the PDC always
> includes one unsuccessful pass thru attempt.
> This initial pass thru validation has an incorrect user password
> (1F1F1F1F......). A SMB reject from the PDC forces the Samba Svr to
> immediately send a second validation with the correct
> encrypted Bell Master Domain user password.
> It would be nice to get rid of the first bad validation attempt.
What you are seeing is being done deliberately.
The problem is that some versions of MS Windows NT have a bug when
used as a password server when Samba is set up to use "security=server"
(Note that this is *NOT* a problem when using "security=domain").
The NT server accepts a user logon request with a bad password as
a "guest" login attempt, and logs the user on as the guest user.
The bug is that the NT server doesn't tell the Samba server
that this is what it has done (it doesn't set the guest bit
that is designed for this use in the protocol). Thus the
Samba server cannot tell if a user entered a bad password
and was logged on as guest, or entered a correct user name
and password and was logged on as the correct user.
The severity of this bug may be imagined if a user attempts
to access the Samba server as user "root" with a bad password,
and the Samba server trusted the NT server to authenticate
this.....
Thus, Samba performs a logon request with a deliberately
bad password and checks to see if that request succeeded.
If it did, then the NT server suffers from the bug and cannot
be used for "security=server" authentication. If it fails
then we know this server is correct.
It is this first deliberate invalid connection request that
people are seeing in the NT event log, but currently there
seems no way around this so long as there are NT servers
out there that have this bug.